Fault diagnosis can be accomplished by several techniques, including decision trees, case based analysis, and Bayesian networks. Each of these techniques requires narrowing the set of possible causes and solutions by answering a series of questions. When the information is stored in a remote data repository, considerable time is spent transmitting questions and subsequent answers between the user and the data repository.
A fault diagnosis session consists of the user responding to a series of questions (or sets of questions). The response to each question (or set of questions) reduces the set of possible causes of the fault and determines the next question (or set of questions) to be posed. This process repeats until one of the following conditions is true:                the number of possible causes of the fault is reduced to one (in which case, the cause is uniquely determined);        the number of possible causes of the fault is reduced to zero (in which case, the cause cannot be determined); or        no further questions are available that will further reduce the number of causes (in which case, there remain multiple possible causes of the fault).        
Each cycle of the diagnosis session has the following three steps:                (1) Select a question (or set of questions) to present to the user and determine the set of acceptable user responses. Note that the specific algorithm used to select one question (or set of questions) from the many potential questions distinguishes the various approaches to the problem known as case based reasoning, Bayesian networks, decision trees, etc. The specific approach is not important to the subject invention; any question selection algorithm may be employed. Similarly unimportant to the subject invention is the particular weighting scheme or measure employed to evaluate each potential question's suitability to be posed next.        
(2) Present the selected question (or set of questions) to the user along with a description of the set of acceptable responses. Note that depending on the number of acceptable responses, various presentation methods may be employed to prompt the user's response. If the number is small, the system might display an itemized list of all acceptable responses as tokens or icons for the user to select. If the list is large, the system might display a text entry field for free-form entry of the response along with a description of the set of acceptable responses. With free-form entry, a parser and validation function must establish that the user's response is valid. The present invention extends to all methods of describing the valid set of responses and all methods of presenting them to the user for selection.
(3) Collect the User's Response.
The basic unit of communication between the system and user in step (2) of the diagnosis session is the question to be posed and the set of potential valid answers to the question. The basic unit of communication between the user and system in step (3) of the diagnosis session is the user's actual response.
The question selection process in step (1) may require, as input, a list of all previously posed questions along with the actual user response to each question. These question-answer pairs form the current state of the process.
The question selection process in step (1) also requires as input:                a set of possible causes of faults;        a set of questions that can be posed to the user to diagnose the fault; and        a set of valid answers for each question.        
In the most trivial scenario, one pass through the process, selecting and presenting one question (and establishing one question-answer pair), will suffice to resolve the fault. However, most scenarios will require at least one more pass through the process with a follow-up question (establishing an additional question-answer pair) prior to resolving the fault. In the general scenario, this process will repeat many times, presenting a new question-answer set to the user each time (and establishing an additional question-answer pair each time) before reaching one of the terminal conditions listed above.
When the database, the question selection algorithm, and the presentation method all reside on one dedicated single-user machine, latency due to data flows between the system and user are minimized. There are no network dependencies to slow the session (or cause it to completely fail) as data moves between the system and user. Similarly, state information is directly available to all steps of the process. The drawback to the single-user solution is the potentially large database of faults, questions, and answers that must be downloaded to the stand-alone client. The latency due to downloading and installing a large database may more than offset the gains of local data flows.
In contrast to the single-client solution, the standard client-server solution places the database and all three steps of the fault diagnosis process upon the server. It offloads to the client only the extremely simple sub-tasks of displaying the question and potential answers (all pre-formatted on the server) and capturing the user's selection. Due to the simplistic use of the client, client-server solutions do not generally allow users to enter free-form text since this requires a sophisticated set of processing functions (parser, validation, and error processing functions) to ensure the user enters valid text. Instead, all valid responses must be enumerated explicitly by the server. This can be awkward when the set of valid responses is large (e.g., all valid twelve digit error codes).
Since the database and all three steps of the fault diagnosis process reside on the server, standard client-server solutions transmit one question (and its accompanying set of valid responses) from the server to the client during each pass through the process. The user's choice is transmitted back to the server, which then repeats the process, selecting a new question and sending it again to the client. Thus, each pass through the process requires two network transmissions and one server interaction.
This results in 2n network transmissions and n server processes for n question-answer interactions. The many server interactions slow server response and impede scalability to multiple users. The many network transmissions further slow response to the user, in addition to increasing the number of opportunities for failure in the middle of the session. Additionally, the process state information must either be transmitted with each interaction (further slowing response) or be stored on the server (further impeding server scalability). Storing the process state information on the server also means that this information must eventually be cleaned up, creating time-out problems for clients who have taken a break in the middle of a fault diagnosis session.